FIG. 1 is a conceptual diagram of a conventional four layer architecture for network communications, such as that on which the Internet is built. As seen in FIG. 1, an application layer is provided that uses the services of a network layer. The network layer uses the services of a data link layer which uses the services of a physical layer. Each layer provides a level of abstraction such that the layer above it does not need to know the details of the layer(s) below. For example, the application layer needs to know the details of how to communicate with the network layer but does not need to know the details of the data link layer or the physical layer. Thus, the applications in the application layer and the users need not know the details of the connectivity network in order to communicate over it.
The current and evolving paradigm of IP application development treats the Internet (and subtending intranets) as a ubiquitous connectivity infrastructure and designs and implements each application at its edge in an autonomous manner, complete with all the supporting capabilities that the application needs. In this paradigm, the degree of convergence has advanced to encompass ubiquitous IP connectivity, in contrast to the older paradigm in which different types of applications would use their own connectivity/transport infrastructure (voice telephony on wired and wireless circuit switched networks, video on Digital Broadcast Satellite (DBS) and Hybrid Fiber Coax (HFC) infrastructures, email/IM and information services on the Internet, signaling and control on SS7, etc.). Many current Internet applications are developed and offered by entities that do not own a connectivity infrastructure. Instead, these applications run on other networks such as the public Internet (which is a best effort connectionless delivery mechanism). Such entities are often called third party service providers—to distinguish them from the Network Service Providers (NSPs)—and their applications are called third party applications. This state of application architecture is depicted in FIG. 2 where the application layer of FIG. 1 is decomposed into a collection of substantially independent application stacks. The collection of shapes in each application stack represent a set of supporting features/capabilities needed by the application for its proper functioning. Many of these supporting capabilities may be common across different applications as indicated in FIG. 2.
The convergence of connectivity/transport technologies has resulted in work in developing Next Generation Networks. The term Next Generation Networks (NGN) is used herein to refer to a fully converged network that provides a variety of advanced services (e.g., voice, video, data, signaling/control, management, connectivity, etc.). A service is a set of well-defined capabilities offered to customers (who can be end users or other service providers that may enhance the service and offer it to end users) and for which customers can potentially be billed. From a service provider's perspective, a service can emanate from any layer of the architecture. For example, physical layer services could include leasing of physical media like fiber to customers by facility-based providers. Data link services can provide layer 2 switched point to point connectivity, e.g., an ATM Permanent Virtual Circuit (PVC) between two customer locations. Network services emanate from the network layer and provide routed connectivity to customers, e.g., a network based Virtual Private Network (VPN) service. Application services are offered to customers from the application layer, for example VoIP, video on demand, etc. Any service above the physical layer would transparently use the services of lower layers (either from the same provider or a different provider) in ways that are typically not visible to the customer.
Several efforts to support application services on NGNs have been proposed. For example, the IP Multimedia Core Network Subsystem (IMS) is an architectural framework specified by 3GPP (3rd Generation Partnership Project) as a foundation for IP-based services in third generation mobile systems. Its specifications are being created as an evolved part of the GSM Core Network (CN). Its design objective is to efficiently support applications involving multiple media components, such as video, audio, and tools like shared online whiteboards, with the possibility to add and drop component(s) during the session. These applications are called IP Multimedia applications (or “services”), and are based on an Internet Engineering Task Force (IETF) defined session control capability, which, along with multimedia bearers, utilizes the IP-Connectivity Access Network (this may include an equivalent set of services to the relevant subset of Circuit-Switched services).
The IMS may enable PLMN (Public Land Mobile Network) operators to offer to their subscribers, multimedia services based on and built upon Internet applications, services and protocols. Such services may be developed by PLMN operators and/or other third party suppliers including those in the Internet space using the mechanisms provided by the Internet and the IMS. IMS may enable the convergence of, and access to, voice, video, messaging, data and web-based technologies for the wireless user, and combine the growth of the Internet with the growth in mobile communications.
Support of these applications is based on the principle that the network is able to dissociate different flows within the multimedia session. These flows are typically used to carry the data resulting from the different media components of the application, and so have different Quality of Service characteristics. As the network becomes aware of these characteristics, a more efficient handling of the resources is possible. It also enables the networks to dissociate the session negotiation from the establishment of bearers.
In order to achieve access independence and maintain good interoperability with wireline terminals across the Internet, the IP multimedia subsystem attempts to be conformant to IETF Internet standards and relevant Requests for Comments (RFCs). Therefore, the interfaces specified do conform, as far as possible, to IETF standards for the cases where an IETF protocol has been selected, e.g., SIP.
To transport IMS signaling and user data, IMS entities use the bearer services provided by the PS (Packet Switched) domain and the Radio Access Network, referred to as the “bearer network” in the IMS specifications. With some exceptions, the PS domain and the Access Network consider IMS signaling and IMS applications flows as user data flows, hence the minimum impact on non-IMS entities. As part of the bearer services offered by the PS domain to the IMS, the PS domain supports the handover functionality for maintaining service continuity while the terminal changes location.
The complete solution for the support of IP multimedia applications includes terminals, IP-Connectivity Access Networks (IP-CAN), and the functional elements of IMS. An example of an IP-Connectivity Access Network is the GPRS core network with GERAN (GPRS/EDGE) and/or UTRAN (UMTS Radio Access Networks). The IP multimedia subsystem utilizes the IP-CAN to transport multimedia signaling and bearer traffic. The IP-CAN maintains the service while the terminal moves and hides these moves from the IP multimedia subsystem.
The IMS architecture has been designed to allow services to be provided by both the Home Network (which contains the user's IMS subscription) and by the Local Network (or visited network, which allows IMS subscriber access through a trust relationship with the home network).
Within the Home Network, the IMS will support IMS subscriber access to both operator-provided services (such as CAMEL-based and SIP-based), as well as third party-provided OSA-based services (through the provision of an OSA/Parlay API between the third party Application Server (AS) and the network).
Within the Local (visited) Network, the IMS can provide services of a local nature to visiting users (inbound roamers). There will be a standardized mechanism to access these local services, and the mechanism to access local services shall be exactly the same for home users and inbound roamers. There will also be a standardized mechanism for the UE (User Equipment) that is registered in the IMS, to receive and/or retrieve information about the available local services. It also will be possible to advertise local services to a registered UE, independent of whether the UE has an active SIP session. Local services may be presented e.g., by directing the user to a web page.
The IMS architecture is based on the principle that the service control of Home subscribed services for a roaming subscriber is in the Home network, e.g., the Serving-CSCF is located in the Home network. The IMS network architecture is illustrated in FIG. 3. Services can be provided within two possible scenarios: The service platform (AS) can be located either in the Home Network, or in an external service platform. The external service platform (OSA-AS) could be located in either the visited network or in a third party platform. The standardized way for secure third party access to IMS services is via the OSA framework. In these scenarios, the roles that the CSCF plays are described as follows. The Proxy-CSCF shall enable the session control signaling to be passed to the Serving-CSCF. The Serving-CSCF is located in the home network and shall invoke the service logic.
Referring to FIG. 3, the IMS may include the following entities:
Proxy-Call Session Control Function (P-CSCF): this is the “first contact point” of IMS. It is located in the same network as the GGSN (visited or home network, shown as being in the visited network in FIG. 3). Its main task is to select the I-CSCF of the Home Network of the user. It also performs some local analysis (e.g., number translation, QoS, admission control, policing, . . . ).
Interrogating-CSCF (I-CSCF): this is the “main entrance” to the home network: it selects (with the help of HSS) the appropriate S-CSCF.
Serving-CSCF (S-CSCF): it performs the actual session control: it handles the SIP requests, performs the appropriate actions (e.g., requests the home and visited networks to establish the bearers), and forwards the requests to the S-CSCF/external IP network of other end users as applicable. The S-CSCF might be specialized for the provisioning of a (set of service(s).
In addition, the interworking functions and entities, not shown in FIG. 3, are defined for interconnection with legacy networks (PSTN, GSM, GSM+GPRS, UMTS, etc.) as BGCF, IM-MGW, and so on. Note that from Release 5 onwards, the name of HLR has been changed into “HSS” (Home Subscriber Server) to emphasize that this database contains not only location-related data but also subscription-related data, like the list of services the user is able to get and the associated parameters.
From the perspective of dynamic behavior, the following is an order of events: a PS-domain bearer (a PDP context in GPRS) must be established, for use in conveying the IMS signaling between the UE and the S-CSCF; and other PS-domain bearers are established between the UE and the other end-party to transport the data generated by the IMS application.
FIG. 4 provides a Functional Model of 3GPP Release 6 entities and their relationships, showing the Circuit-Switched (CS) domain, the Packet-Switched (PS) domain, the CAMEL Service Environment (CSE), the IP Multimedia Core Network Subsystem (IMS), as well as other non-core elements.
In addition to IMS, a Joint Working Group composed of the ETSI TISPAN OSA Project, 3GPP, 3GPP2, the Parlay Group, and some member companies of the JAIN community, has been drafting an Application Programming Interface (API) specification for third party service applications, known as the Open Service Access API, or OSA/Parlay API. Using this API, application service developers may access and utilize network functionality offered by network operators through an open, standardized interface.
OSA/Parlay is, therefore, a mediator API between telecom networks and third-party applications, and provides a secure interface between network operators and application servers. The Joint Working Group derives its specifications from a UML model of the OSA API. Using the latest document and code generation techniques, the detailed technical description documents, the IDL code, WSDL code, and Java API are all produced from a single source UML model. This ensures alignment between all versions and all formats of the API. ETSI publishes the master specification of the APIs. The Parlay Group point to this published ETSI standard instead of re-publishing the specification.
3GPP maintains its own specification, TS 29.198, which has the same structure as the ETSI specification. Each part of TS 29.198 is a subset or a copy of the ETSI specification. In addition to OSA/Parlay APIs, the Joint Working Group has issued OSA/Parlay X Web Services Specifications. The Parlay X Web Services Specifications define a set of highly abstracted telecommunication capabilities (i.e., a simplified Parlay API) following a simple request/response model using Web Services (SOAP/XML) technologies.
The OSA/Parlay architecture is primarily focused on network and protocol independent service APIs for third party access in fixed and mobile networks as shown in FIG. 5.
The OSA/Parlay APIs are split into three types of interfaces classes:
Interface classes between the OSA/Parlay Applications and Framework, which provide applications with basic mechanisms (e.g., authentications, service discovery, service subscription) that enable them to access the service capabilities in the network.
Interface classes between the OSA/Parlay Applications and Services, which are individual Services that may be required by the OSA/Parlay Application.
Interface classes between the Framework and the Services, which provide the mechanism for multi-vendor deployments.
The Framework API controls access to Services Capabilities, only allowing trusted applications (typically from third parties, or those that have passed its authentication tests), to discover and use the Services offered, and providing basic infrastructure functionality, such as integrity management. Typically, implementations of the Service APIs would sit inside networks, while the Framework would sit somewhere where it has access to the Services, and where applications have access to it. The Framework can host Services provided by different suppliers and even existing within different networks. Using the APIs, applications can be independently deployed of the Service itself. As the applications make use of the Gateway, the actual location of the Services is irrelevant to them.
To provide secure access to service capabilities in the network to third-party applications, the Framework API provides basic mechanisms that must be executed prior to offering and activating applications:
Authentication: the application must be authenticated before it is allowed to use any other OSA/Parlay interfaces.
Authorization: determines what a previously authenticated application is allowed to do. Authentication must precede authorization. Once authenticated, an application is authorized to access certain Service Capability Features.
Discovery: after successful authentication, applications can utilize the available Framework interfaces and the Discovery interface to obtain information on authorized network Service Capability Features. The Discovery interface can be used at any time after successful authentication.
Establishment of service agreement: before an application can interact with a network Service Capability Feature, a service agreement must be established.
Access control: the framework provides access control functions to restrict an application's access to only Service Capability Features and service data for the security level, context, domain, etc. authorized for the application.
The network capabilities are described in Parlay specifications as Services (see FIG. 6).
The OSA/Parlay Framework is a gateway component in support of Services and OSA/Parlay applications. The Service APIs each offer an abstraction of a certain class of features contained within the network, thereby facilitating easier access to network capabilities to applications residing outside of the network. Examples of these Service APIs include Multi Party Call Control, which allows applications to create third-party calls and to intercept calls or call attempts, and Mobility, which allows an application to discover the location and status of an end-user. The Services APIs in Parlay Release 4.1, published in 2003, include Call Control (Generic Call Control, Multi-party, Multimedia, and Conference Call Control), Mobility (User Location and Status), Generic User Interaction, Generic Messaging, Terminal Capabilities, Data Session Control, Connectivity Manager, Presence and Availability Management, Policy Management, Account Management and Charging.
The Microsoft New Services Architecture Service Delivery Platform is a next generation service framework envisioned by Microsoft as the evolution of Service Oriented Architecture (SOA) to support the delivery of new services across devices and networks. A description of the Microsoft SDP is found in the white paper entitled “Microsoft Service Delivery Platform Technical Overview.” Microsoft's SDP features include the following:
Session Management for service collaboration that handles the context in which services will interact with one another;
Service Logic that defines how services will be organized as part of a session;
Identity & Security Management for handling the different modes of identity distribution and security between multiple services;
Resource & QoS Management that defines how services will be reserved and allocated and how QoS will be handled at the service level;
Service Catalog that defines the existence and availability of the services and their extended technical description; and
Subscriber profile Management for handling the different representations of a subscriber.
In general, SDP is Microsoft's service framework to address the problems associated with services proliferation, heterogeneous environments, multiple administrative domains, loose coupling, and dynamic aggregation. SDP provides a common framework of reusable building block components for application developers to develop and integrate voice and data applications, such as VoIP and VoD integrated infrastructures.